home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc889 < prev    next >
Text File  |  1995-07-25  |  27KB  |  685 lines

  1. Network Working Group                                   D.L.  Mills
  2. Request for Comments:  889                              December 1983
  3.  
  4.  
  5.                           Internet Delay Experiments
  6.  
  7. This memo reports on some measurement experiments and suggests some possible
  8. improvements to the TCP retransmission timeout calculation.  This memo is
  9. both a status report on the measurements and advice to implementers of TCP.
  10.  
  11. 1.  Introduction
  12.  
  13.      This memorandum describes two series of experiments designed to explore
  14. the transmission characteristics of the Internet system.  One series of
  15. experiments was designed to determine the network delays with respect to
  16. packet length, while the other was designed to assess the effectiveness of the
  17. TCP retransmission-timeout algorithm specified in the standards documents.
  18. Both sets of experiments were conducted during the October - November 1983
  19. time frame and used many hosts distributed throughout the Internet system.
  20.  
  21.      The objectives of these experiments were first to accumulate experimental
  22. data on actual network paths that could be used as a benchmark of Internet
  23. system performance, and second to apply these data to refine individual TCP
  24. implementations and improve their performance.
  25.  
  26.      The experiments were done using a specially instrumented measurement host
  27. called a Fuzzball, which consists of an LSI-11 running IP/TCP and various
  28. application-layer protocols including TELNET, FTP and SMTP mail.  Among the
  29. various measurement packages is the original PING (Packet InterNet Groper)
  30. program used over the last six years for numerous tests and measurements of
  31. the Internet system and its client nets.  This program contains facilities to
  32. send various kinds of probe packets, including ICMP Echo messages, process the
  33. reply and record elapsed times and other information in a data file, as well
  34. as produce real-time snapshot histograms and traces.
  35.  
  36.      Following an experiment run, the data collected in the file were reduced
  37. by another set of programs and plotted on a Peritek bit-map display with color
  38. monitor.  The plots have been found invaluable in the indentification and
  39. understanding of the causes of netword glitches and other "zoo" phenomena.
  40. Finally, summary data were extracted and presented in this memorandum.  The
  41. raw data files, including bit-map image files of the various plots, are
  42. available to other experimenters upon request.
  43.  
  44.      The Fuzzballs and their local-net architecture, called DCN, have about
  45. two-dozen clones scattered worldwide, including one (DCN1) at the Linkabit
  46. Corporation offices in McLean, Virginia, and another at the Norwegian
  47. Telecommunications Adminstration (NTA) near Oslo, Norway.  The DCN1 Fuzzball
  48. is connected to the ARPANET at the Mitre IMP by means of 1822 Error Control
  49. Units operating over a 56-Kbps line.  The NTA Fuzzball is connected to the
  50. NTARE Gateway by an 1822 interface and then via VDH/HAP operating over a
  51. 9.6-Kbps line to SATNET at the Tanum (Sweden) SIMP.  For most experiments
  52. described below, these details of the local connectivity can be ignored, since
  53. only relatively small delays are involved.
  54.  
  55.  
  56.  
  57.  
  58. Internet Delay Experiments                                              Page 2
  59. D.L. Mills
  60.  
  61.  
  62.      The remote test hosts were selected to represent canonical paths in the
  63. Internet system and were scattered all over the world.  They included some on
  64. the ARPANET, MILNET, MINET, SATNET, TELENET and numerous local nets reachable
  65. via these long-haul nets.  As an example of the richness of the Internet
  66. system connectivity and the experimental data base, data are included for
  67. three different paths from the ARPANET-based measurement host to London hosts,
  68. two via different satellite links and one via an undersea cable.
  69.  
  70. 2.  Packet Length Versus Delay
  71.  
  72.      This set of experiments was designed to determine whether delays across
  73. the Internet are significantly influenced by packet length.  In cases where
  74. the intrinsic propagation delays are high relative to the time to transmit an
  75. individual packet, one would expect that delays would not be strongly affected
  76. by packet length.  This is the case with satellite nets, including SATNET and
  77. WIDEBAND, but also with terrestrial nets where the degree of traffic
  78. aggregation is high, so that the measured traffic is a small proportion of the
  79. total traffic on the path.  However, in cases where the intrinsic propagation
  80. delays are low and the measured traffic represents the bulk of the traffic on
  81. the path, quite the opposite would be expected.
  82.  
  83.      The objective of the experiments was to assess the degree to which TCP
  84. performance could be improved by refining the retransmission-timeout algorithm
  85. to include a dependency on packet length.  Another objective was to determine
  86. the nature of the delay characteristic versus packet length on tandem paths
  87. spanning networks of widely varying architectures, including local-nets,
  88. terrestrial long-haul nets and satellite nets.
  89.  
  90. 2.1.  Experiment Design
  91.  
  92.      There were two sets of experiments to measure delays as a function of
  93. packet length.  One of these was based at DCN1, while the other was based at
  94. NTA.  All experiments used ICMP Echo/Reply messages with embedded timestamps.
  95. A cycle consisted of sending an ICMP Echo message of specified length, waiting
  96. for the corresponding ICMP Reply message to come back and recording the
  97. elapsed time (normalized to one-way delay).  An experiment run, resulting in
  98. one line of the table below, consisted of 512 of these volleys.
  99.  
  100.      The length of each ICMP message was determined by a random-number
  101. generator uniformly distributed between zero and 256.  Lengths less than 40
  102. were rounded up to 40, which is the minimum datagram size for an ICMP message
  103. containing timestamps and just happens to also be the minimum TCP segment
  104. size.  The maximum length was chosen to avoid complications due to
  105. fragmentation and reassembly, since ICMP messages are not ordinarily
  106. fragmented or reassembled by the gateways.
  107.  
  108.      The data collected were first plotted as a scatter diagram on a color
  109. bit-map display.  For all paths involving the ARPANET, this immediately
  110. revealed two distinct characteristics, one for short (single-packet) messages
  111. less than 126 octets in length and the other for long (multi-packet) messages
  112.  
  113.  
  114.  
  115. Internet Delay Experiments                                              Page 3
  116. D.L. Mills
  117.  
  118.  
  119. longer than this.  Linear regression lines were then fitted to each
  120. characteristic with the results shown in the following table.  (Only one
  121. characteristic was assumed for ARPANET-exclusive paths.) The table shows for
  122. each host the delays, in milliseconds, for each type of message along with a
  123. rate computed on the basis of these delays.  The "Host ID" column designates
  124. the host at the remote end of the path, with a letter suffix used when
  125. necessary to identify a particular run.
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172. Internet Delay Experiments                                              Page 4
  173. D.L. Mills
  174.  
  175.  
  176. Host    Single-packet   Rate    Multi-packet    Rate    Comments
  177. ID      40      125     (bps)   125     256     (bps)
  178. ---------------------------------------------------------------------------
  179. DCN1 to nearby local-net hosts (calibration)
  180. DCN5    9                               13      366422  DMA 1822
  181. DCN8    14                              20      268017  Ethernet
  182. IMP17   22                              60      45228   56K 1822/ECU
  183. FORD1   93                              274     9540    9600 DDCMP base
  184. UMD1    102                             473     4663    4800 synch
  185. DCN6    188                             550     4782    4800 DDCMP
  186. FACC    243                             770     3282    9600/4800 DDCMP
  187. FOE     608                             1917    1320    9600/14.4K stat mux
  188.  
  189. DCN1 to ARPANET hosts and local nets
  190. MILARP  61      105     15358   133     171     27769   MILNET gateway
  191. ISID-L  166     263     6989    403     472     15029   low-traffic period
  192. SCORE   184     318     5088    541     608     15745   low-traffic period
  193. RVAX    231     398     4061    651     740     11781   Purdue local net
  194. AJAX    322     578     2664    944     1081    7681    MIT local net
  195. ISID-H  333     520     3643    715     889     6029    high-traffic period
  196. BERK    336     967     1078    1188    1403    4879    UC Berkeley
  197. WASH    498     776     2441    1256    1348    11379   U Washington
  198.  
  199. DCN1 to MILNET/MINET hosts and local nets
  200. ISIA-L  460     563     6633    1049    1140    11489   low-traffic period
  201. ISIA-H  564     841     2447    1275    1635    2910    high-traffic period
  202. BRL     560     973     1645    1605    1825    4768    BRL local net
  203. LON     585     835     2724    1775    1998    4696    MINET host (London)
  204. HAWAII  679     980     2257    1817    1931    9238    a long way off
  205. OFFICE3 762     1249    1396    2283    2414    8004    heavily loaded host
  206. KOREA   897     1294    1712    2717    2770    19652   a long, long way off
  207.  
  208. DCN1 to TELENET hosts via ARPANET
  209. RICE    1456    2358    754     3086    3543    2297    via VAN gateway
  210.  
  211. DCN1 to SATNET hosts and local nets via ARPANET
  212. UCL     1089    1240    4514    1426    1548    8558    UCL zoo 
  213. NTA-L   1132    1417    2382    1524    1838    3339    low-traffic period
  214. NTA-H   1247    1504    2640    1681    1811    8078    high-traffic period
  215.  
  216. NTA to SATNET hosts
  217. TANUM   107                             368     6625    9600 bps Tanum line
  218. ETAM    964                             1274    5576    Etam channel echo
  219. GOONY   972                             1256    6082    Goonhilly channel echo
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229. Internet Delay Experiments                                              Page 5
  230. D.L. Mills
  231.  
  232.  
  233. 2.2 Analysis of Results
  234.  
  235.      The data clearly show a strong correlation between delay and length, with
  236. the longest packets showing delays two to three times the shortest.  On paths
  237. via ARPANET clones the delay characteristic shows a stonger correlation with
  238. length for single-packet messages than for multi-packet messages, which is
  239. consistent with a design which favors low delays for short messages and high
  240. throughputs for longer ones.
  241.  
  242.      Most of the runs were made during off-peak hours.  In the few cases where
  243. runs were made for a particular host during both on-peak and off-peak hours,
  244. comparison shows a greater dependency on packet length than on traffic shift.
  245.  
  246.      TCP implementors should be advised that some dependency on packet length
  247. may have to be built into the retransmission-timeout estimation algorithm to
  248. insure good performance over lossy nets like SATNET.  They should also be
  249. advised that some Internet paths may require stupendous timeout intervals
  250. ranging to many seconds for the net alone, not to mention additional delays on
  251. host-system queues.
  252.  
  253.      I call to your attention the fact that the delays (at least for the
  254. larger packets) from ARPANET hosts (e.g.  DCN1) to MILNET hosts (e.g.  ISIA)
  255. are in the same ballpark as the delays to SATNET hosts (e.g.  UCL)!  I have
  256. also observed that the packet-loss rates on the MILNET path are at present not
  257. neglible (18 in 512 for ISIA-2).  Presumably, the loss is in the gateways;
  258. however, there may well be a host or two out there swamping the gateways with
  259. retransmitted data and which have a funny idea of the "normal" timeout
  260. interval.  The recent discovery of a bug in the TOPS-20 TCP implementation,
  261. where spurious ACKs were generated at an alarming rate, would seem to confirm
  262. that suspicion.
  263.  
  264. 3.  Retransmission-Timeout Algorithm
  265.  
  266.      One of the basic features of TCP which allow it to be used on paths
  267. spanning many nets of widely varying delay and packet-loss characteristics is
  268. the retranansmission-timeout algorithm, sometimes known as the "RSRE
  269. Algorithm" for the original designers.  The algorithm operates by recording
  270. the time and initial sequence number when a segment is transmitted, then
  271. computing the elapsed time for that sequence number to be acknowledged.  There
  272. are various degrees of sophistication in the implementation of the algorithm,
  273. ranging from allowing only one such computation to be in progress at a time to
  274. allowing one for each segment outstanding at a time on the connection.
  275.  
  276.      The retransmission-timeout algorithm is basically an estimation process.
  277. It maintains an extimate of the current roundtrip delay time and updates it as
  278. new delay samples are computed.  The algorithm smooths these samples and then
  279. establishes a timeout, which if exceeded causes a retransmission.  The
  280. selection of the parameters of this algorithm are vitally important in order
  281. to provide effective data transmission and avoid abuse of the Internet system
  282. by excessive retransmissions.  I have long been suspicious of the parameters
  283.  
  284.  
  285.  
  286. Internet Delay Experiments                                              Page 6
  287. D.L. Mills
  288.  
  289.  
  290. suggested in the specification and used in some implementations, especially in
  291. cases involving long-delay paths involving lossy nets.  The experiment was
  292. designed to simulate the operation of the algorithm using data collected from
  293. real paths involving some pretty leaky Internet plumbing.
  294.  
  295. 3.1.  Experiment Design
  296.  
  297.      The experiment data base was constructed of well over a hundred runs
  298. using ICMP Echo/Reply messages bounced off hosts scattered all over the world.
  299. Most runs, including all those summarized here, consisted of 512 echo/reply
  300. cycles lasting from several seconds to twenty minutes or so.  Other runs
  301. designed to detect network glitches lasted several hours.  Some runs used
  302. packets of constant length, while others used different lengths distributed
  303. from 40 to 256 octets.  The maximum length was chosen to avoid complications
  304. fragmented or reassembled by the gateways.
  305.  
  306.      The object of the experiment was to simulate the packet delay
  307. distribution seen by TCP over the paths measured.  Only the network delay is
  308. of interest here, not the queueing delays within the hosts themselves, which
  309. can be considerable.  Also, only a single packet was allowed in flight, so
  310. that stress on the network itself was minimal.  Some tests were conducted
  311. during busy periods of network activity, while others were conducted during
  312. quiet hours.
  313.  
  314.      The 512 data points collected during each run were processed by a program
  315. which plotted on a color bit-map display each data point (x,y), where x
  316. represents the time since initiation of the experiment the and y the measured
  317. delay, normalized to the one-way delay.  Then, the simulated
  318. retransmission-timeout algorithm was run on these data and its computed
  319. timeout plotted in the same way.  The display immediately reveals how the
  320. algorithm behaves in the face of varying traffic loads, network glitches, lost
  321. packets and superfluous retransmissions.
  322.  
  323.      Each experiment run also produced summary statistics, which are
  324. summarized in the table below.  Each line includes the Host ID, which
  325. identifies the run.  The suffix -1 indicates 40-octet packets, -2 indicates
  326. 256-octet packets and no suffix indicates uniformly distributed lengths
  327. between 40 and 256.  The Lost Packets columns refer to instances when no ICMP
  328. Reply message was received for thirty seconds after transmission of the ICMP
  329. Echo message, indicating probable loss of one or both messages.  The RTX
  330. Packets columns refer to instances when the computed timeout is less than the
  331. measured delay, which would result in a superfluous retransmission.  For each
  332. of these two types of packets the  column indicates the number of instances
  333. and the Time column indicates the total accumulated time required for the
  334. recovery action.
  335.  
  336.      For reference purposes, the Mean column indicates the computed mean delay
  337. of the echo/reply cycles, excluding those cycles involving packet loss, while
  338. the CoV column indicates the coefficient of variation.  Finally, the Eff
  339.  
  340.  
  341.  
  342.  
  343. Internet Delay Experiments                                              Page 7
  344. D.L. Mills
  345.  
  346.  
  347. column indicates the efficiency, computed as the ratio of the total time
  348. accumulated while sending good data to this time plus the lost-packet and
  349. rtx-packet time.
  350.  
  351.      Complete sets of runs were made for each of the hosts in the table below
  352. for each of several selections of algorithm parameters.  The table itself
  353. reflects values, selected as described later, believed to be a good compromise
  354. for use on existing paths in the Internet system.
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400. Internet Delay Experiments                                              Page 8
  401. D.L. Mills
  402.  
  403.  
  404. Host    Total   Lost Packets    RTX Packets     Mean    CoV     Eff
  405. ID      Time            Time            Time    
  406. -------------------------------------------------------------------
  407. DCN1 to nearby local-net hosts (calibration)
  408. DCN5    5       0       0       0       0       11      .15     1
  409. DCN8    8       0       0       0       0       16      .13     1
  410. IMP17   19      0       0       0       0       38      .33     1
  411. FORD1   86      0       0       1       .2      167     .33     .99
  412. UMD1    135     0       0       2       .5      263     .45     .99
  413. DCN6    177     0       0       0       0       347     .34     1
  414. FACC    368     196     222.1   6       9.2     267     1.1     .37
  415. FOE     670     3       7.5     21      73.3    1150    .69     .87
  416. FOE-1   374     0       0       26      61.9    610     .75     .83
  417. FOE-2   1016    3       16.7    10      47.2    1859    .41     .93
  418.  
  419. DCN1 to ARPANET hosts and local nets
  420. MILARP  59      0       0       2       .5      115     .39     .99
  421. ISID    163     0       0       1       1.8     316     .47     .98
  422. ISID-1  84      0       0       2       1       163     .18     .98
  423. ISID-2  281     0       0       3       17      516     .91     .93
  424. ISID *  329     0       0       5       12.9    619     .81     .96
  425. SCORE   208     0       0       1       .8      405     .46     .99
  426. RVAX    256     1       1.3     0       0       499     .42     .99
  427. AJAX    365     0       0       0       0       713     .44     1
  428. WASH    494     0       0       2       2.8     960     .39     .99
  429. WASH-1  271     0       0       5       8       514     .34     .97
  430. WASH-2  749     1       9.8     2       17.5    1411    .4      .96
  431. BERK    528     20      50.1    4       35      865     1.13    .83
  432.  
  433. DCN1 to MILNET/MINET hosts and local nets
  434. ISIA    436     4       7.4     2       15.7    807     .68     .94
  435. ISIA-1  197     0       0       0       0       385     .27     1
  436. ISIA-2  615     0       0       2       15      1172    .36     .97
  437. ISIA *  595     18      54.1    6       33.3    992     .77     .85
  438. BRL     644     1       3       1       1.9     1249    .43     .99
  439. BRL-1   318     0       0       4       13.6    596     .68     .95
  440. BRL-2   962     2       8.4     0       0       1864    .12     .99
  441. LON     677     0       0       3       11.7    1300    .51     .98
  442. LON-1   302     0       0       0       0       589     .06     1
  443. LON-2   1047    0       0       0       0       2044    .03     1
  444. HAWAII  709     4       12.9    3       18.5    1325    .55     .95
  445. OFFICE3 856     3       12.9    3       10.3    1627    .54     .97
  446. OFF3-1  432     2       4.2     2       6.9     823     .31     .97
  447. OFF3-2  1277    7       39      3       41.5    2336    .44     .93
  448. KOREA   1048    3       14.5    2       18.7    1982    .48     .96
  449. KOREA-1 506     4       8.6     1       2.2     967     .18     .97
  450. KOREA-2 1493    6       35.5    2       19.3    2810    .19     .96
  451.  
  452. DCN1 to TELENET hosts via ARPANET
  453. RICE    677     2       6.8     3       12.1    1286    .41     .97
  454.  
  455.  
  456.  
  457. Internet Delay Experiments                                              Page 9
  458. D.L. Mills
  459.  
  460.  
  461. RICE-1  368     1       .1      3       2.3     715     .11     .99
  462. RICE-2  1002    1       4.4     1       9.5     1930    .19     .98
  463.  
  464. DCN1 to SATNET hosts and local nets via ARPANET
  465. UCL     689     9       26.8    0       0       1294    .21     .96
  466. UCL-1   623     39      92.8    2       5.3     1025    .32     .84
  467. UCL-2   818     4       13.5    0       0       1571    .15     .98
  468. NTA     779     12      38.7    1       3.7     1438    .24     .94
  469. NTA-1   616     24      56.6    2       5.3     1083    .25     .89
  470. NTA-2   971     19      71.1    0       0       1757    .2      .92
  471.  
  472. NTA to SATNET hosts and local nets
  473. TANUM   110     3       1.6     0       0       213     .41     .98
  474. GOONY   587     19      44.2    1       2.9     1056    .23     .91
  475. ETAM    608     32      76.3    1       3.1     1032    .29     .86
  476. UCL     612     5       12.6    2       8.5     1154    .24     .96
  477.  
  478. Note:  * indicates randomly distributed packets during periods of high ARPANET
  479. activity.  The same entry without the * indicates randomly distributed packets
  480. during periods of low ARPANET activity.
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514. Internet Delay Experiments                                             Page 10
  515. D.L. Mills
  516.  
  517.  
  518. 3.2 Discussion of Results
  519.  
  520.      It is immediately obvious from visual inspection of the bit-map display
  521. that the delay distribution is more-or-less Poissonly distributed about a
  522. relatively narrow range with important exceptions.  The exceptions are
  523. characterized by occasional spasms where one or more packets can be delayed
  524. many times the typical value.  Such glitches have been commonly noted before
  525. on paths involving ARPANET and SATNET, but the true impact of their occurance
  526. on the timeout algorithm is much greater than I expected.  What commonly
  527. happens is that the algorithm, when confronted with a short burst of
  528. long-delay packets after a relatively long interval of well-mannered behavior,
  529. takes much too long to adapt to the spasm, thus inviting many superfluous
  530. retransmissions and leading to congestion.
  531.  
  532.      The incidence of long-delay bursts, or glitches, varied widely during the
  533. experiments.  Some of them were glitch-free, but most had at least one glitch
  534. in 512 echo/reply volleys.  Glitches did not seem to correlate well with
  535. increases in baseline delay, which occurs as the result of traffic surges, nor
  536. did they correlate well with instances of packet loss.  I did not notice any
  537. particular periodicity, such as might be expected with regular pinging, for
  538. example;  however, I did not process the data specially for that.
  539.  
  540.      There was no correction for packet length used in any of these
  541. experiments, in spite of the results of the first set of experiments described
  542. previously.  This may be done in a future set of experiments.  The algorithm
  543. does cope well in the case of constant-length packets and in the case of
  544. randomly distributed packet lengths between 40 and 256 octets, as indicated in
  545. the table.  Future experiments may involve bursts of short packets followed by
  546. bursts of longer ones, so that the speed of adaptation of the algorithm can be
  547. directly deterimend.
  548.  
  549.      One particularily interesting experiment involved the FOE host
  550. (FORD-FOE), which is located in London and reached via a 14.4-Kbps undersea
  551. cable and statistical multiplexor.  The multiplexor introduces a moderate mean
  552. delay, but with an extremely large delay dispersion.  The specified
  553. retransmission-timeout algorithm had a hard time with this circuit, as might
  554. be expected;  however, with the improvments described below, TCP performance
  555. was acceptable.  It is unlikely that many instances of such ornery circuits
  556. will occur in the Internet system, but it is comforting to know that the
  557. algorithm can deal effectively with them.
  558.  
  559. 3.3.  Improvments to the Algorithm
  560.  
  561.      The specified retransmission-timeout algorithm, really a first-order
  562. linear recursive filter, is characterized by two parameters, a weighting
  563. factor F and a threshold factor G.  For each measured delay sample R the delay
  564. estimator E is updated:
  565.  
  566.                                 E = F*E + (1 - F)*R .
  567.  
  568.  
  569.  
  570.  
  571. Internet Delay Experiments                                             Page 11
  572. D.L. Mills
  573.  
  574.  
  575. Then, if an interval equal to G*E expires after transmitting a packet, the
  576. packet is retransmitted.  The current TCP specification suggests values in the
  577. range 0.8 to 0.9 for F and 1.5 to 2.0 for G.  These values have been believed
  578. reasonable up to now over ARPANET and SATNET paths.
  579.  
  580.      I found that a simple change to the algorithm made a worthwhile change in
  581. the efficiency.  The change amounts to using two values of F, one (F1) when R
  582. < E in the expression above and the other (F2) when R >= E, with F1 > F2.  The
  583. effect is to make the algorithm more responsive to upward-going trends in
  584. delay and less respnsive to downward-going trends.  After a number of trials I
  585. concluded that values of F1 = 15/16 and F2 = 3/4 (with G = 2) gave the best
  586. all-around performance.  The results on some paths (FOE, ISID, ISIA) were
  587. better by some ten percent in efficiency, as compared to the values now used
  588. in typical implementations where F = 7/8 and G = 2.  The results on most paths
  589. were better by five percent, while on a couple (FACC, UCL) the results were
  590. worse by a few percent.
  591.  
  592.      There was no clear-cut gain in fiddling with G.  The value G = 2 seemed
  593. to represent the best overall compromise.  Note that increasing G makes
  594. superfluous retransmissions less likely, but increases the total delay when
  595. packets are lost.  Also, note that increasing F2 too much tends to cause
  596. overshoot in the case of network glitches and leads to the same result.  The
  597. table above was constructed using F1 = 15/16, F2 = 3/4 and G = 2.
  598.  
  599.      Readers familiar with signal-detection theory will recognize my
  600. suggestion as analogous to an ordinary peak-detector circuit.  F1 represents
  601. the discharge time-constant, while F2 represents the charge time-constant.  G
  602. represents a "squelch" threshold, as used in voice-operated switches, for
  603. example.  Some wag may be even go on to suggest a network glitch should be
  604. called a netspurt.
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628. Internet Delay Experiments                                             Page 12
  629. D.L. Mills
  630.  
  631.  
  632. Appendix.  Index of Test Hosts
  633.  
  634. Name    Address         NIC Host Name
  635. -------------------------------------
  636. DCN1 to nearby local-net hosts (calibration)
  637. DCN5    128.4.0.5       DCN5
  638. DCN8    128.4.0.8       DCN8
  639. IMP17   10.3.0.17       DCN-GATEWAY
  640. FORD1   128.5.0.1       FORD1
  641. UMD1    128.8.0.1       UMD1
  642. DCN6    128.4.0.6       DCN6
  643. FACC    128.5.32.1      FORD-WDL1
  644. FOE     128.5.0.15      FORD-FOE
  645.  
  646. DCN1 to ARPANET hosts and local nets
  647. MILARP  10.2.0.28       ARPA-MILNET-GW
  648. ISID    10.0.0.27       USC-ISID
  649. SCORE   10.3.0.11       SU-SCORE
  650. RVAX    128.10.0.2      PURDUE-MORDRED
  651. AJAX    18.10.0.64      MIT-AJAX
  652. WASH    10.0.0.91       WASHINGTON
  653. BERK    10.2.0.78       UCB-VAX
  654.  
  655. DCN1 to MILNET/MINET hosts and local nets
  656. ISIA    26.3.0.103      USC-ISIA
  657. BRL     192.5.21.6      BRL-VGR
  658. LON     24.0.0.7        MINET-LON-EM
  659. HAWAII  26.1.0.36       HAWAII-EMH
  660. OFFICE3 26.2.0.43       OFFICE-3
  661. KOREA   26.0.0.117      KOREA-EMH
  662.  
  663. DCN1 to TELENET hosts via ARPANET
  664. RICE    14.0.0.12       RICE
  665.  
  666. DCN1 to SATNET hosts and local nets via ARPANET
  667. UCL     128.16.9.0      UCL-SAM
  668. NTA     128.39.0.2      NTARE1
  669.  
  670. NTA to SATNET hosts and local nets
  671. TANUM   4.0.0.64        TANUM-ECHO
  672. GOONY   4.0.0.63        GOONHILLY-ECHO
  673. ETAM    4.0.0.62        ETAM-ECHO
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.